パスの確立を要求するｉｐネットワークにおけるルーティングの最適性の向上

专利摘要:
パスの確立を要求するＩＰネットワークにおけるルーティングの最適性を向上させるシステムおよび関連する方法であって、次のうちの１つまたは複数を含む：複数の通信エレメントを含む第１および第２のネットワーククラウドであって、ネットワーククラウドの中の複数の通信エレメントのうちの通信エレメントが第１および第２の通信エレメントであり、ネットワーククラウドは境界を有し、複数の通信エレメントのそれぞれはこの境界を越えてそれぞれのネットワーククラウド外のどの他の通信エレメント間の接続性をも見ることができない、ネットワーククラウドと、第１の通信エレメントと第２の通信エレメントとの間の明示的な最適ネットワーク経路を自動的に計算し、ネットワーククラウドの中のすべての通信エレメントの全体像を有し、計算された明示的な最適ネットワーク経路をルーティングエンジンに提供する、パス計算エレメントと、提供された明示的な最適ネットワーク経路を使用して第１の通信エレメントから第２の通信エレメントへの第１のネットワーククラウドおよび第２のネットワーククラウドを介するパスをコミッションすることと、計算された明示的な最適ネットワーク経路を使用してパスを確立することと、計算された明示的な最適ネットワーク経路の障害時に、計算された明示的な最適ネットワーク経路より劣る代替経路に切り換えて正常に機能するようにすることと、コミッションされたパスを計算された明示的な最適ネットワーク経路に再ネゴシエートするように試みることと、明示的な最適ネットワーク経路が再び利用可能であると判定することと、その経路が再び利用可能であると判定されるとき、コミッションされたパスを計算された明示的な最適ネットワーク経路に切り換えること。
公开号:JP2011505737A
申请号:JP2010535502
申请日:2008-11-19
公开日:2011-02-24
发明作者:ドルガノウ，アンドルー
申请人:アルカテル−ルーセント；
IPC主号:H04L12-56

专利说明:

[0001] 本発明は、概して、インターネットプロトコル（ＩＰ）ネットワークにおけるルーティングに関する。]
背景技術

[0002] ＩＰネットワーク、テレコミュニケーションなどのコンピュータネットワーキングにおいて、マルチプロトコルラベルスイッチング（ＭＰＬＳ）は、パケット交換ネットワークの系列に属するデータ伝送メカニズムである。ＭＰＬＳは、一般に伝統的な定義のレイヤ２（データリンク層）とレイヤ３（ネットワーク層）の間にあるとみなされるＯＳＩモデルのレイヤで動作し、ゆえにしばしば「レイヤ２．５」プロトコルと呼ばれる。ＭＰＬＳは、データグラムサービスモデルを提供する回線ベースの顧客とパケット交換の顧客の双方に、統合されたデータ伝送サービスを提供するように設計されている。ＭＰＬＳは、ＩＰパケット、ならびに固有の非同期転送モード（ＡＴＭ）、同期型光ネットワーキング（ＳＯＮＥＴ）、およびイーサネット（登録商標）のフレームなど、多種多様なトラフィックを伝送するために使用される。]
[0003] 疑似回線（ＰＷ）は、パケット交換ネットワーク（ＰＳＮ）上で固有サービスをエミュレーションするものである。固有サービスは、レイヤ２またはＳＯＮＥＴ接続、ＡＴＭ、フレームリレー、イーサネット（登録商標）、低速時分割多重（ＴＤＭ）、もしくはＳＯＮＥＴ／ＳＤＨである可能性があり、ＰＳＮは、ＭＰＬＳ、ＩＰ（ＩＰｖ４もしくはＩＰｖ６）、またはＬ２ＴＰｖ３である可能性がある。より詳細にはＰＷは、ＰＳＮにわたってレイヤ２プロトコルデータユニット（ＰＤＵ）を運ぶために２つのプロバイダエッジ（ＰＥ）ノード間に確立されるトンネルである。]
[0004] マルチセグメント化されたＰＷ（ＭＳ−ＰＷ）は、複数のＰＳＮドメイン、すなわち１つまたは複数のサービスプロバイダ（ＳＰ）ネットワーク、または同じＳＰネットワーク内の複数のネットワーク（例えばアクセスおよびコアネットワーク）を横断するものである。より詳細にはＭＳ−ＰＷは、単一のポイントツーポイントＰＷとして動作および機能する、２つ以上の隣接したＰＷセグメントがスタティックまたはダイナミックに構成されたセットである。ＭＳ−ＰＷの各端部は、最終プロバイダエッジ（Ｕ−ＰＥ）装置で終わっている。]
[0005] 本明細書に記載する対象物は、ＭＰＬＳおよびＭＳ−ＰＷなど、ネットワークを介するルーティングに関する。ルーティングは、ソースと宛先との間でデータを運ぶために好適な経路を見つけるプロセスである。ルーティングは、サービスの品質、ポリシー、もしくはルーティングサービスのユーザに対する価格設定など、一連の制約の影響を受ける可能性がある。]
[0006] 制約に基づくパス計算は、ＭＰＬＳネットワークにおけるトラフィックエンジニアリングの戦略的要素である。これは、トラフィックがたどる、ネットワークを介するパスを決定するために使用され、設定されるラベル交換パス（ＬＳＰ）ごとに経路を提供する。]
[0007] パス計算は、これまで管理システムまたは各ＬＳＰのヘッドエンドにおいて行われてきた。しかし大規模な、マルチドメインのネットワークにおけるパス計算は非常に複雑である可能性があり、通常ネットワークエレメントで利用できる以上の計算力およびネットワーク情報を必要とする可能性があり、さらに管理システムによって提供できる以上にダイナミックである必要がある。]
発明が解決しようとする課題

[0008] パス計算エレメント（ＰＣＥ）は、インターネットエンジニアリングタスクフォース（ＩＥＴＦ）により、ネットワークグラフに基づいてネットワークのパスまたは経路を計算し、計算上の制約を適用することができるエンティティ（コンポーネント、アプリケーション、またはネットワークノード）として定義されている。したがって、ＰＣＥは、単一サービスまたは一連のサービスのための複雑なパスを計算することができるエンティティである。ＰＣＥは、ネットワークリソースを認識して高度なパス計算のために複数の制約を考慮する能力を有するネットワークノード、ネットワーク管理局、または専用計算プラットフォームである場合がある。ＰＣＥの応用は、ＭＰＬＳトラフィックエンジニアリングのためにラベル交換パスを計算することを含む。したがって、ＰＣＥは、経路計算が実際のパケット転送から幾分切り離されたネットワーク像を有し、ルータまたはリンクの障害などの一時的な状態を無視したネットワーク像を有する可能性があり、最適に及ばないルーティングの原因となる。１つまたは複数のＰＣＥを使用するシステムおよび方法など、パスの確立を要求するＩＰネットワークにおいてルーティングの最適性を向上させるシステムおよび方法が必要であることは明らかである。]
課題を解決するための手段

[0009] 本発明の前述の目的および利点は、様々な例示的実施形態によって達成可能である目的および利点を説明するものであって、実現されることが可能であると考えられる利点を網羅するまたは限定するものではない。ゆえに、様々な例示的実施形態のこれらの目的および利点ならびに他の目的および利点は、本明細書で具体化されて、または当業者には理解可能である変形物を考慮して変更されて、本明細書の記載から明らかとなり、あるいは様々な例示的実施形態を実行することから習得可能である。したがって、本発明は、様々な例示的実施形態で本明細書に示して説明する新規の方法、配列、組合せ、および改善にある。]
[0010] パスの確立を要求するＩＰネットワークにおいてルーティングの最適性を高める目下の必要を踏まえて、様々な例示的実施形態の概要を提示する。次の概要では、いくらか簡略化および省略を行う場合があるが、これは様々な例示的実施形態のいくつかの態様を強調して伝えることを意図するものであり、その範囲を限定することを意図するものではない。当業者が本発明の概念を構築して利用することを可能にするために適切な好ましい例示的実施形態についての詳細な説明を、後の部分で行う。]
[0011] 様々な例示的実施形態は、ＡＴＭスマート恒久仮想回線（ＳＰＶＣ）を含む。このような様々な実施形態では、ＳＰＶＣをコミッションするときに明示的なパスが提供される。またこのような様々な実施形態では、障害から回復するためにダイナミックルーティングが使用される。]
[0012] マルチセグメントの疑似回線のようなコネクション型サービスのために回転可能および最適なパスをダイナミックに見つけるシステムおよび方法が必要である。この問題への１つの解決法は、ルーティングプロトコルを使用して、マルチセグメントの疑似回線をダイナミックに確立するために必要とされる情報を分配する。したがって、様々な例示的実施形態は、ルータに依存してパス計算を行う。しかしながら、このような諸実施形態は、一般に単一のネットワークトポロジに限定されている。例えば、様々な例示的諸実施形態は、単一のＡＳオープンショーテストパスファースト（ＯＳＰＦ）トポロジに対して機能する。]
[0013] このように、様々な例示的諸実施形態は、ネットワークの現在の状態に基づいて経路を計算する。しかしながら、このような手法は、しばしば最適な経路ではない経路を計算する結果となる。これは、大部分のネットワークにおいて、一時的な障害、デコミッショニング、および他に経路を変更されたパスが日常的に発生するためである。通常、これらの事象のすべては結果として、ネットワークの現在の状態に基づいて計算される経路を、最適な経路ではないように変えてしまう。]
[0014] 様々な例示的実施形態は、集中型のＰＣＥを取り入れている。様々な例示的実施形態では、ＰＣＥがネットワークリソースを管理し、ネットワークの現在の状態が最適な動作状態ではない場合でさえ、最適な動作状態に基づいてネットワークを介して１つまたは複数の計算されたパスを返す。様々な例示的実施形態では、ＰＣＥはまた、最適なパスを計算するときにルータから要求される基準を考慮する。]
[0015] 多くの実装は、複雑なネットワークトポロジを含む。したがって、様々な例示的実施形態では、１つのＰＣＥが１つまたは複数のさらなるＰＣＥと通信して全パスの最適な部分を決定する。したがって、様々な例示的実施形態では、最適なパス全体は、複数のＰＣＥによって区分されて決定され、最適なパス全体がルータに返される。さらに、有益および必要であることは少ないが、様々な例示的実施形態では複数のＰＣＥが、あまり複雑ではないネットワークトポロジで実装される。使用するＰＣＥの数を最小限にすることが好ましいと考えられる。したがって、所望されるパス全体のトポロジの複雑さに対処するためにどの１つのＰＣＥでも苦心するときに、複数のＰＣＥを使用するにとどまることが好ましいと思われる。]
[0016] 上記に基づいて、様々な例示的実施形態では、パス計算クライアント（ＰＣＣ）からの経路要求によって、オンデマンドの計算が作動される。また、様々な例示的実施形態では、経路の計算は、最適ではない可能性があるネットワークの現在の状態に基づいてＰＣＥによって行われる。これは、上記および下記のユーザについて当てはまる。同様に、様々な例示的実施形態では、パスの最適化が試みられるたびに、ルータがＰＣＥと通信する。このような諸実施形態によりルータは、パスが求められるたびに、改善されたパスが利用できるかどうかの判定を行うことができる。]
[0017] 様々な例示的実施形態をよりよく理解するために、添付の図面を参照する。]
図面の簡単な説明

[0018] パスの確立を要求するＩＰネットワークにおいてルーティングの最適性を向上させるためのシステムの第１の例示的実施形態の概略図である。
パスの確立を要求するＩＰネットワークにおいてルーティングの最適性を向上させるためのシステムの第２の例示的実施形態の概略図である。
パスの確立を要求するＩＰネットワークにおいてルーティングの最適性を向上させるための方法の一例示的実施形態のフローチャートである。]
実施例

[0019] 本明細書に記載される様々な例示的実施形態は、次のようなパス計算エレメント通信プロトコル（ＰＣＥＰ）から発展させる。様々な例示的実施形態では、ネットワークマネージャがＩＰネットワークを介してパスをコミッションすることができる。様々な例示的実施形態では、パスがネットワークを介してコミッションされるときに、ネットワークを通る明示的な経路が与えられる。様々な例示的実施形態では、明示的な経路は、光ネットワークのルーティングに基づいて計算される。最適なネットワークルーティングのためにいかなる特定のシステムまたはアプリケーションにおいて与えられる基準も変化する可能性があることを理解されたい。したがって、様々な例示的実施形態では、光ネットワークのルーティングのための基準が指定されることもまた明らかであるはずである。]
[0020] 様々な例示的実施形態では、ルータは、計算された明示的な最適ネットワーク経路に基づいてパスを確立しようと試みる。この最適経路に障害がある場合、ルータは、最適ではないパスを確立しようと試みる。様々な例示的実施形態では、現在知られているまたは最近開発された手段により、最適ではないパスが確立される。例えば様々な例示的実施形態では、知られているＰＣＥＰまたはＯＳＰＦ技術を用いて最適ではないパスが確立される。]
[0021] また、様々な例示的実施形態では、確立された最適なパスが、最適なパスが存在している間に経路を変更される必要があるときはいつでも、最適ではないパスを確立することへの同じまたは同様の手法が使用されることは明らかである。同様に、様々な例示的実施形態では、最適ではないパスが使用されているときはいつでも、最適なパスへの切り換えが無事達成されるまで、最適なパスに切り換えるための試みが定期的に行われることが可能であることは明らかである。これについては次に、図面を参照してさらに詳細に説明する。]
[0022] 図中では、同様の参照符号が同様の構成要素またはステップを指し、様々な例示的実施形態の一般的な態様を開示している。]
[0023] 図１は、パスの確立を要求するＩＰネットワークにおいてルーティングの最適性を向上させるためのシステム１００の第１の例示的実施形態の概略図である。このシステム１００は、第１のネットワーククラウド１０５と、第２のネットワーククラウド１１０と、第３のネットワーククラウド１１５とを含んでいる。] 図１
[0024] 第１のネットワーククラウド１０５、第２のネットワーククラウド１１０、および第３のネットワーククラウド１１５のそれぞれが、ネットワークへの管理上の境界または運用上の境界を表している。したがって、様々な例示的実施形態では、第１のネットワーククラウド１０５、第２のネットワーククラウド１１０、および第３のネットワーククラウド１１５のそれぞれが、図示された境界内で実装されるサマライゼーションを表している。大規模に実装することの問題によりサマライゼーションのこのような管理上または運用上の境界を実装することがしばしば望ましいことを理解されたい。]
[0025] 第１のネットワーククラウド１０５、第２のネットワーククラウド１１０、および第３のネットワーククラウド１１５のそれぞれが、２つのルータを備えて描かれている。したがって、第１のネットワーククラウド１０５はルータＡ１２０およびルータＢ１２５を含み、第２のネットワーククラウド１１０はルータＣ１３０およびルータＤ１３５を含み、第３のネットワーククラウド１１５はルータＥ１４０およびルータＦ１４５を含む。]
[0026] 例示的システム１００に示しているように、ルータＢ１２５、ルータＣ１３０、ルータＤ１３５、およびルータＥ１４０は、それぞれのネットワーククラウドの中のエッジノードである。したがって、ルータＢ１２５は、第１のネットワーククラウド１０５の右端に示されたエッジノードであり、ルータＣは、第２のネットワーククラウド１１０の左端に示されたエッジノードであり、ルータＤは、第２のネットワーククラウド１１０の右端に示されたエッジノードであり、ルータＥ１４０は、第３のネットワーククラウド１１５の左端に示されたエッジノードである。ルータＡ１２０は、第１のネットワーククラウド１０５の境界内に含まれるルータである。同様にルータＦ１４５は、第３のネットワーククラウド１１５の境界内に含まれるルータである。]
[0027] 所与のルータは、そのルータが属するクラウドの詳細なビューを有するにすぎず、他のクラウドについてはサマライズされたビューを有するにすぎない。したがって、ルータＡ１２０およびルータＢ１２５は、第１のクラウド１０５の詳細なビューを有するにすぎない。ルータＣ１３０およびルータＤ１３５は、第２のクラウド１１０の詳細なビューを有するにすぎない。ルータＥ１４０およびルータＦ１４５は、第３のクラウド１１５の詳細なビューを有するにすぎない。]
[0028] 本明細書に記載する様々な例示的実施形態は、ルータＡ１２０とルータＦ１４５の間で所望される例示的通信パスに関連して説明する。しかしながら、ルータＡ１２０とルータＦ１４５の間の本明細書に記載する例示的通信は、ありとあらゆる通信システムにおける２つのルータ間の事実上すべての通信パスの例示とすることは明らかである。]
[0029] 同様に、例示的システム１００の第１のネットワーククラウド１０５、第２のネットワーククラウド１１０、および第３のネットワーククラウド１１５のそれぞれに示した２つのルータに加えて、第１のネットワーククラウド１０５、第２のネットワーククラウド１１０、および第３のネットワーククラウド１１５のそれぞれにさらに多くのルータが存在することは明らかである。正しくは、図を簡単にするために、第１のネットワーククラウド１０５、第２のネットワーククラウド１１０、および第３のネットワーククラウド１１５のそれぞれについて、システム１００では２つのルータのみが示されている。]
[0030] したがって、様々な例示的実施形態におけるルータＡ１２０からルータＢ１２５への通信パス１７０は、図示した直接の通信パスではないことを理解されたい。正しくは、様々な例示的実施形態では、ルータＡ１２０からルータＢ１２５への通信パス１７０は、システム１００では示されていない、第１のネットワーククラウド１０５内の任意の数のさらなるルータを通過する。同様に、様々な例示的実施形態では、ルータＥ１４０からルータＦ１４５への通信パス１９０は、システム１００に示すような直接の通信パスではなく、システム１００では示されていない、任意の数のさらなるルータまたは他の通信エレメントを通って進む通信パスである。これは、第２のネットワーククラウド１１０のルータＣ１３０からルータＤ１３５への通信パス１８０についても同様である。]
[0031] エッジルータＢ１２５からエッジルータＣ１３０への通信パス１７５は、２つのネットワーククラウド、具体的には第１のネットワーククラウド１０５と第２のネットワーククラウド１１０の間で一方のエッジルータからもう一方のエッジルータへ進む通信パスであるので、直接の通信パスであるということを理解されたい。同様に、ルータＤ１３５からルータＥ１４０への通信パス１８５もまた、別々のネットワーククラウドの２つのエッジルータ間の直接の通信パスである。]
[0032] 様々な例示的実施形態では、第１のネットワーククラウド１０５、第２のネットワーククラウド１１０、および第３のネットワーククラウド１１５は、ＯＳＰＦエリアにマップされる。このような実施形態では、それぞれのクラウド内の様々なルータが、接続回線をアドバタイズすることができる。アドバタイズされる接続回線は、ＰＷが接続されるルータの後方の端末である。したがって、接続回線は、ＰＷにはルータの宛先であるのでこのように呼ばれる。]
[0033] 様々な例示的実施形態では、ＯＳＰＦを使用してアドバタイズされる接続回線およびクラウドトポロジは、隣接クラウドに伝えられる前にエリア境界のルータ１２５、１３０、１３５、１４０によってサマライズされる。しかしながら、このような伝播が例えばルータＡ１２０からルータＦ１４５へ進むとき、接続回線およびネットワークトポロジは、伝播が第１のクラウド１０５から第２のクラウド１１０などと移るときにサマライズされる。]
[0034] ルータＡ１２０からルータＦ１４５へのネットワーク通信全体は、より小さい部分に分割されるので、接続回線および関連するルーティング情報の伝播が第１のネットワーククラウド１０５、第２のネットワーククラウド１１０、および第３のネットワーククラウド１１５から出るたびに、あるレベルのサマライズが行われる。その他の場合、ネットワークは単一ルータでは大規模になりすぎてしまう。したがって、上記のような伝播の後に、ルータＦ１４５は、ルータＡ１２０への特定の接続回線アドレスがあることを知り、ルータＦ１４５は、ルータＦ１４５からルータＡ１２０に伝えるためにたどることができる経路に関するサマライズされた情報を有することになる。]
[0035] ネットワークサーバの状態が変化するときはいつでも、また管理ポリシーがルータＡ１２０とルータＦ１４５の間のパスに影響を与えるように変化するときはいつでも、このような変化はしばしば接続回線のアドバタイズメントに影響を与えるので、ダイナミックプロトコルが有益であることは明らかである。したがって、ＯＳＰＦの実施形態では、ルータＡ１２０は、処理の一定のタイミング遅延内で、ネットワークの現在の状態に基づいてルータＦ１４５へのパスを知る。]
[0036] システム１００では、ＰＣＥ１５０は通信パス１５５を経由して第１のネットワーククラウド１０５と通信している。同様に、ＰＣＥ１５０は通信パス１６０を介して第２のネットワーククラウド１１０と通信している。同じく、ＰＣＥ１５０は通信パス１６５を介して第３のネットワーククラウド１１５と通信している。通信パス１５５、通信パス１６０、および通信パス１６５のおかげで、ＰＣＥ１５０は、第１のネットワーククラウド１０５、第２のネットワーククラウド１１０、および第３のネットワーククラウド１１５のそれぞれからサマライズされていない情報を蓄積することができる。]
[0037] したがってＰＣＥ１５０は、第１のネットワーククラウド１０５、第２のネットワーククラウド１１０、および第３のネットワーククラウド１１５の中のエレメントのすべてのビューを有する。したがってＰＣＥ１５０は、あるレベルのサマライゼーションを回避することができる。これは、ＰＣＥ１５０が、第１のネットワーククラウド１０５、第２のネットワーククラウド１１０、および第３のネットワーククラウド１１５内にある通信エレメントからより多くの情報を有することができるためである。]
[0038] 上記のように、第１のネットワーククラウド１０５、第２のネットワーククラウド１１０、および第３のネットワーククラウド１１５のそれぞれの中のエレメントは、自身の中のサマライズされていないルーティング情報を見ることができるにすぎない。したがって、第１のネットワーククラウド１０５内のエレメントは、第１のネットワーククラウド１０５外のエレメントについての詳細情報を見ることができない。これには、第２のネットワーククラウド１１０および第３のネットワーククラウド１１５の中のエレメントが含まれる。同様に、ルータＣ１３０およびルータＤ１３５など、第２のネットワーククラウド１１０の中の通信エレメントは、第１のネットワーククラウド１０５および第３のネットワーククラウド１１５の中の通信エレメントなど、第２のネットワーククラウド１１０外の通信エレメントについての詳細情報を見ることができない。同じく、ルータＥ１４０およびルータＦ１４５など、第３のネットワーククラウド１１５内の通信エレメントは、ルータＡ１２０とルータＦ１４５の間のパスを確立するために必要である、第１のネットワーククラウド１０５および第２のネットワーククラウド１１０の中の通信エレメントなど、第３のネットワーククラウド１１５外の通信エレメントについての詳細情報を見ることができない。]
[0039] したがって、ＰＣＥ１５０は、ルータＡ１２０とルータＦ１４５の間の最適なおよび現在最適な（すなわち最適に及ばない原因となる一時的な状態になる）パスを確立するために必要である通信エレメントのすべてについての詳細な情報を見ることができる、システム１００の中の唯一のエレメントである。システム１００に示す様々なエレメントによって行われる機能については、図３と関連して以下にさらに詳細に説明する。] 図３
[0040] 様々な例示的実施形態では、ＰＣＥ１５０は既存ルータの内部に実装される。他の例示的実施形態では、ＰＣＥ１５０はルータ外に実装される。したがって、様々な例示的実施形態では、ＰＣＥ１５０は最適なボックスの一部として実装される。様々な例示的実施形態では、ＰＣＥ１５０は、最初はルータ外に実装された後に、ルータに組み込まれる。]
[0041] 図２は、パスの確立を要求するＩＰネットワークにおいてルーティングの最適性を向上させるためのシステム２００の第２の例示的実施形態の概略図である。システム２００中のエレメントの多くは、システム１００中のエレメントにも使用される参照符号を使用して識別される。したがって、このようなエレメントについては、システム２００に関連して別途に述べない。このようなエレメントをシステム１００に関連して上述したことが、システム２００のこれらのエレメントの表示に当てはまると理解されたい。] 図２
[0042] システム２００に特有のエレメントは、ＰＣＥ２５０、ＰＣＥ２６０、ＰＣＥ２７０、通信パス２５５、通信パス２６５、通信パス２７５、および通信パス２８５を含む。通信パス２７５は、ＰＣＥ２６０がＰＣＥ２５０と通信できるようにする。同様に通信パス２８５は、ＰＣＥ２７０がＰＣＥ２５０と通信できるようにする。]
[0043] ＰＣＥ２５０、ＰＣＥ２６０、およびＰＣＥ２７０のそれぞれは、第１のネットワーククラウド１０５、第２のネットワーククラウド１１０、および第３のネットワーククラウド１１５のうちの１つと通信している。具体的には、ＰＣＥ２６０は、通信パス２５５を介して第１のネットワーククラウド１０５と通信している。ＰＣＥ２５０は、通信パス１６０を介して第２のネットワーククラウド１１０と通信している。ＰＣＥ２７０は、通信パス２６５を介して第３のネットワーククラウド１１５と通信している。]
[0044] したがって、システム２００は、たとえＰＣＥ２５０、ＰＣＥ２６０、およびＰＣＥ２７０のいずれも全経路を見ることができないとしても、互いと通信している複数のＰＣＥがルータＡ１２０からルータＦ１４５への全経路を確立することができるシステムを表している。正しくは、ＰＣＥ２５０、ＰＣＥ２６０、およびＰＣＥ２７０は互いと通信して、共同でＰＣＥ１５０と同様に機能することができる。]
[0045] さらにＰＣＥ２５０、ＰＣＥ２６０、およびＰＣＥ２７０は、ＰＣＥ１５０に関して説明した実装と同様に実装される。したがって、ＰＣＥ１５０、ＰＣＥ２５０、ＰＣＥ２６０、およびＰＣＥ２７０は、クラウドのエッジ上のルータ、具体的にはルータＢ１２５、ルータＣ１３０、ルータＤ１３５、および／またはルータＥ１４０に様々な例示的実施形態で実装される。ＰＣＥ１５０、ＰＣＥ２５０、ＰＣＥ２６０、およびＰＣＥ２７０がクラウドのエッジ上のルータに実装された様々な例示的実施形態では、２つのルータ間の最良のパスを求めるルータＡ１２０またはルータＦ１４５からの要求の結果、複数のＰＣＥから個々に取得された情報を合わせて結合し、情報が統合的に構築されるようにする。このような実施形態は、ＰＣＥの分散型モデルの別の例を表している。]
[0046] システム２００は、第１のネットワーククラウド１０５、第２のネットワーククラウド１１０、および第３のネットワーククラウド１１５のトポロジの複雑さがＰＣＥ１５０の運用能力を検証または超過し始めた実施において、システム１００に優って好ましいと考えられている。３つのＰＣＥ、すなわち２５０、２６０、２７０の間でトポロジを評価する負荷を共有することによって、システム２００は、第１のネットワーククラウド１０５、第２のネットワーククラウド１１０、および第３のネットワーククラウド１１５のトポロジの複雑さがＰＣＥ１５０の限界を超過または検証する場合でも、システム１００と同じ機能を果たすことができる。]
[0047] いずれか１つのＰＣＥが１つまたは複数のネットワーククラウドにおけるトポロジを処理し、いずれかの数のネットワーククラウドを介した発信元ルータから宛先ルータへの経路を処理するために、いずれかの数のＰＣＥが通信して結合される、ほぼ無数の実施形態が存在することは明らかである。したがって、いずれか１つのＰＣＥが、機能的限界までいずれかの数のクラウドの全体像を処理することは明らかである。]
[0048] 図３は、パスの確立を要求するＩＰネットワークにおいてルーティングの最適性を向上させるための方法３００の一例示的実施形態のフローチャートである。方法３００は、ステップ３０５から始まり、ステップ３１０へと続く。ステップ３１０では、明示的な（ｅｘｐｌｉｃｉｔ）最適ネットワーク経路が自動的に計算される。これは、パス１７０を通ってルータＢ１２０へ、パス１７５を通ってルータＣ１３０へ、パス１８０を通ってルータＤ１３５へ、パス１８５を通ってルータＥ１４０へ、パス１９０を通ってルータＦ１４５へ進む、ルータＡ１２０からルータＦ１４５への最適経路をＰＣＥが計算することに対応する。] 図３
[0049] 方法３００は、ステップ３１０に続いてステップ３１５へ進む。ステップ３１５では、ステップ３１０で自動的に計算された明示的な最適ネットワークルータが、ルーティングエンジンに提供される。したがって、ＰＣＥによって決定された明示的な最適ネットワーク経路が、ルーティングエレメントに提供される。]
[0050] 様々な例示的実施形態では、ステップ３１５は、１つのネットワークまたは複数のネットワーククラウド１０５、１１０、１１５が存在する場合に事実上いつでも発生することは明らかである。したがって、ステップ３１５は、パスがコミッションされるとき、パスがコミッションされる前、パスがコミッションされた後などに、様々な例示的実施形態で行われる。ステップ３１５が様々な例示的実施形態で行われるときの他の例は、自動的にまたは手動で生成されるパスの需要または要求に応じるとき、トポロジの変更またはリンクの障害がパスに影響を与えるとき、およびルータが作動するときが含まれる。]
[0051] 方法３００は、ステップ３１５に続いてステップ３２０へ進む。ステップ３２０では、提供された経路を使用してネットワークを介してパスがコミッションされる。次にステップ３２５では、ステップ３１５で提供された経路を使用してネットワークを介してコミッションされたパスが正常であるかどうかを判定する。ステップ３２５において、提供された経路を使用してネットワークを介してコミッションされたパスが正常であると判定されるとき、方法３００はステップ３３０へ進み、確立されるパスは計算された明示的な最適ネットワーク経路を使用する。これは、理想的な状況を表している。ステップ３３０は理想的な状況を表しているので、方法３００はステップ３３０に続いてステップ３６０へ進み、ここで方法３００は停止する。方法３００は、ネットワークトポロジが変化して配置されたパスの最適性を再評価するのに十分であると思われるレベルになると、再開する可能性がある。]
[0052] 一方、ステップ３２５において提供された経路を使用してネットワークを介してコミッションされたパスが正常ではないと判定されたとき、方法３００はステップ３３５へ進む。ステップ３３５では、ルータＡ１２０からルータＦ１４５への代替経路が使用される。上記のように、ステップ３３５では、経路を確立することに代わる、知られているまたは最近開発された代替形態が使用されて経路を確立する。ステップ３３５で使用するように選択された所与の経路については、方法３００はステップ３４０へ進み、３３５からの使用される代替経路はルータＡ１２０とルータＦ１４５との間で正常に確立されるかどうかの評価が行われる。]
[0053] ステップ３３５で使用するように選択された代替経路が正常ではないとステップ３４０で判定されるとき、方法３００はステップ３３５に戻る。その後、使用するように先に選択された代替経路がもう一度試されるか、さらに別の代替経路が使用するように選択される。ステップ３３５で使用するように選択された代替経路がルータＡ１２０とルータＦ１４５との間で正常に確立されているとステップ３４０において判断されると、方法３００はステップ３４５に進む。]
[0054] ステップ３４５では、コミッションされたパスを計算された明示的な最適ネットワーク経路に再ネゴシエートするための試みが継続的に行われる。言い換えれば、様々な例示的実施形態では、最適ではない経路が使用されていることがわかる。したがって、様々な例示的実施形態では、最適ではない経路を最適経路に改善するための試みが継続的に行われる。ゆえに、様々な例示的実施形態では、最適パスは、最適である現在のパスを使用して動作していない様々なネットワークエレメントの背景で走っていることを理解されたい。]
[0055] 様々な例示的実施形態では、ステップ３２０および３３５、もしくはその変形は、ネットワークの現在の状態にかかわらず同時に行われる。したがって、このような実施形態では、パスを求めるルータからの要求は、最適パスと現在のパスを共に同時に通知されることを希望して作成される。言い換えれば、様々な例示的実施形態では、パスを要求するときルータは最適パスか現在のパス、または両方を要求することがある。]
[0056] 方法３００は、ステップ３４５に続いてステップ３５０へ進む。ステップ３５０では、ステップ３２０でコミッションされた、計算された明示的な最適ネットワーク経路が正常に再ネゴシエートされたかどうかの評価が行われる。これは、上記のステップ３２５と非常に似ている。ステップ３５０において、計算された明示的な最適ネットワーク経路が正常に再ネゴシエートされなかったと判定されるとき、方法３００はステップ３４５に戻り、このような試みが継続的に行われる。]
[0057] 最終的には、計算された明示的な最適ネットワーク経路は、ステップ３５０において正常に再ネゴシエートされる。これが行われると、方法３００はステップ３５５へ進む。ステップ３５５では、コミッションされたパスは、ステップ３３５で使用されるように選択されてステップ３４０で正常にネゴシエートされた代替経路から、ステップ３２０でコミッションされた、計算された明示的な最適ネットワーク経路に切り換えられる。これは、ステップ３３０に対応する。]
[0058] したがって、ステップ３５５の後に、ルータＡ１２０とルータＦ１４５との間のパスは最良のパスとなる。ゆえに、方法３００は、ステップ３５５の後にステップ３６０へ進み、ここで方法３００は停止する。]
[0059] 上記に基づき、様々な例示的実施形態により、ネットワークの現在の状態とは対照的にネットワークの構成から決定された最適な経路に基づいた、ネットワークを介する最適パスの確立が可能になる。様々な例示的実施形態では、ＰＣＥＰ技術または同様の技術は、プッシュダウンモデルによって最適パスの概念を配信するための手段を提供するために拡張されることが可能である。言い換えれば、様々な例示的実施形態では、ＰＣＥは、コミッション時にまたはその後のいつでも、経路をプッシュダウンする。]
[0060] 様々な例示的実施形態では、ＰＣＥＰまたは同様の技術は、ルータが、パスを確立するために現在使用可能である経路に加えて最適経路を要求できるように拡張されることが可能である。したがって、様々な例示的実施形態では、プルモデルが拡張されて、経路を最適化するときの試みのたびにＰＣＥと続いて通信する必要がなく、ルータが最適パスを最適化することができるようになることが可能である。こうした実施形態は、ＰＣＥへの動作上の負荷を軽減することは明らかである。]
[0061] 本明細書に記載した対象物の多くの利点は明らかである。例えば、様々な例示的実施形態は、ネットワークのトラフィックエンジニアリング（ＴＥ）に予測を導入する。様々な例示的実施形態では、これは、ルータに最適経路を提供すること、および現在ルータに使用されているパスが提供された最適経路から外れるときはいつでもルータが最適経路を最適化することができるようにすることによって成し遂げられる。本明細書に記載する様々な例示的実施形態のもう一つの利点は、回線が確立される可能性が最大化されながら、同時に再最適化を管理するために必要とされるオーバーヘッドが最小化されることである。]
[0062] 様々な例示的実施形態がシグナリングのオーバーヘッドを最小化することは明らかである。また、様々な例示的実施形態が、パスの最適化に必要な複雑さを最小化することも明らかである。ルータはコミッショニングの前に最適パスを与えられるので、これは、他の理由でも同様である。]
[0063] 上記によれば、様々な例示的実施形態は、ＰＣＥシステムを用いるネットワークにおいてトラフィックエンジニアリングを向上させる。また、様々な例示的実施形態は、最適化の決定をネットワークに分配する。こうした諸実施形態は魅力的であり、有益であることは明らかである。]
[0064] したがって、様々な例示的実施形態は、ＰＣＥが制御するＩＰネットワークを実現するシステムおよび方法である。こうした様々な実施形態では、ＰＣＥはマルチセグメントの疑似回線のために最適経路を計算する。こうした様々な実施形態では、ＰＣＥはネットワーク全体の見通し（ｖｉｓｉｂｉｌｉｔｙ）を有する。したがって様々な例示的実施形態では、第１のネットワーククラウド１０５、第２のネットワーククラウド１１０、または第３のネットワーククラウド１１５などの管理または運用ドメインの境界部で、情報がサマライズされる必要がない。]
[0065] 様々な例示的実施形態は、現在のパスへのオンデマンドのＰＣＥＰ要求へのＰＣＥＰ応答の一部として最適なパスを提供する。また、様々な例示的実施形態は、ＰＣＥからＰＣＣのプッシュモデルに使用されるＰＣＥＰ応答または同様のメッセージの中で最適なパスを提供する。いくつかのこうした実施形態では、プッシュは、最適化される更新を行うことを所望するノードに対してパスを更新するために最適化されるにすぎない。言い換えれば、様々な例示的実施形態では、現在の宛先への現在のパスの要求が行われた後に、最適化がプッシュされる。]
[0066] 様々な例示的実施形態をその一定の例示的態様を特に参照して詳細に説明したが、本発明は他の異なる実施形態が可能であり、本発明の詳細は様々な明らかな点で変更可能であることを理解されたい。当業者には容易に理解されるように、本発明の趣旨および範囲内にありながら、変形形態および変更形態が考えられる。したがって、上記の開示、説明、および図は単に例示の目的のためであって、本発明を決して限定するものではなく、本発明は特許請求の範囲によってのみ定められる。]

权利要求:

請求項1
パスの確立を要求するＩＰネットワークにおけるルーティングの最適性を向上させる方法であって、パス計算エレメントが、第１のネットワーククラウドの中の第１の通信エレメントと第２のネットワーククラウドの中の第２の通信エレメントとの間の明示的な最適ネットワーク経路を自動的に計算することであって、第１のネットワーククラウドおよび第２のネットワーククラウドがそれぞれ複数の通信エレメントを含み、またそれぞれ境界を有し、各ネットワーククラウドの中の複数の通信エレメントのそれぞれがこの境界を越えて各それぞれのネットワーククラウド外の他のどの通信エレメント間の接続性をも見ることができず、パス計算エレメントがネットワーククラウドの中の全通信エレメントの全体像を有することと、パス計算エレメントが計算された明示的な最適ネットワーク経路をルーティングエンジンに提供することと、提供された明示的な最適ネットワーク経路を使用して第１の通信エレメントから第２の通信エレメントへ第１のネットワーククラウドおよび第２のネットワーククラウドを介するパスをコミッションすることと、計算された明示的な最適ネットワーク経路を使用してパスを確立することと、計算された明示的な最適ネットワーク経路の障害時に、計算された明示的な最適ネットワーク経路より劣る代替経路に切り換えて正常に機能するようにすることと、コミッションされたパスを計算された明示的な最適ネットワーク経路に再ネゴシエートしようと試みることと、明示的な最適ネットワーク経路が再び利用可能であると判定することと、その経路が再び利用可能であると判定されるとき、コミッションされたパスを計算された明示的な最適ネットワーク経路に切り換えることとを含む、方法。
請求項2
第１の通信エレメントがルータであり、第２の通信エレメントもまたルータである、請求項１に記載の、パスの確立を要求するＩＰネットワークにおけるルーティングの最適性を向上させる方法。
請求項3
明示的な最適ネットワーク経路を自動的に計算することが、複数のパス計算エレメントによって行われ、複数のパス計算エレメントのそれぞれが複数のパス計算エレメントの１つまたは複数の他のものと通信し、複数のパス計算エレメントのそれぞれが第１のネットワーククラウドおよび第２のネットワーククラウドのうちの少なくとも１つの中の複数の通信エレメントのすべてのビューを有する、請求項１に記載の、パスの確立を要求するＩＰネットワークにおけるルーティングの最適性を向上させる方法。
請求項4
明示的な最適ネットワーク経路を自動的に計算することが、第１の通信エレメントから受信された要求に応答して行われる、請求項１に記載の、パスの確立を要求するＩＰネットワークにおけるルーティングの最適性を向上させる方法。
請求項5
パス計算エレメントがルータの中にある、請求項１に記載の、パスの確立を要求するＩＰネットワークにおけるルーティングの最適性を向上させる方法。
請求項6
パス計算エレメントがルータの中にない、請求項１に記載の、パスの確立を要求するＩＰネットワークにおけるルーティングの最適性を向上させる方法。
請求項7
コミッションされたパスを計算された明示的な最適ネットワーク経路に再ネゴシエートしようと試みることが、この試みが成功するまで継続して行われる、請求項１に記載の、パスの確立を要求するＩＰネットワークにおけるルーティングの最適性を向上させる方法。
請求項8
パス計算エレメントが、第１のネットワーククラウドおよび第２のネットワーククラウドの１つまたは複数のエッジノードの中にある、請求項１に記載の、パスの確立を要求するＩＰネットワークにおけるルーティングの最適性を向上させる方法。
請求項9
明示的な最適ネットワーク経路が通過する１つまたは複数の追加のネットワーククラウドをさらに含み、１つまたは複数のさらなるネットワーククラウドがそれぞれ複数の通信エレメントを含み、またそれぞれ境界を有し、各ネットワーククラウドの複数の通信エレメントのそれぞれがこの境界を越えて各それぞれのネットワーククラウド外の他のどの通信エレメント間の接続性をも見ることができない、請求項１に記載の、パスの確立を要求するＩＰネットワークにおけるルーティングの最適性を向上させる方法。
請求項10
パスの確立を要求するＩＰネットワークにおけるルーティングの最適性を向上させるシステムであって、複数の通信エレメントを含む第１のネットワーククラウドであって、第１のネットワーククラウドの中の複数の通信エレメントのうちの１つが第１の通信エレメントであり、第１のネットワーククラウドが境界を有し、第１のネットワーククラウドの中の複数の通信エレメントのそれぞれはこの境界を越えて第１のネットワーククラウド外の他のどの通信エレメント間の接続性をも見ることができない、第１のネットワーククラウドと、複数の通信エレメントを含む第２のネットワーククラウドであって、第２のネットワーククラウドの中の複数の通信エレメントのうちの１つが第２の通信エレメントであり、第２のネットワーククラウドが境界を有し、第２のネットワーククラウドの中の複数の通信エレメントのそれぞれはこの境界を越えて第２のネットワーククラウド外の他のどの通信エレメント間の接続性をも見ることができない、第２のネットワーククラウドと、第１のネットワーククラウドの中の第１の通信エレメントと第２のネットワーククラウドの中の第２の通信エレメントとの間の明示的な最適ネットワーク経路を自動的に計算し、ネットワーククラウドの中のすべての通信エレメントの全体像を有し、計算された明示的な最適ネットワーク経路をルーティングエンジンに提供するパス計算エレメントと、提供された明示的な最適ネットワーク経路を使用して第１の通信エレメントから第２の通信エレメントへの第１のネットワーククラウドおよび第２のネットワーククラウドを介するパスをコミッションするための手段と、計算された明示的な最適ネットワーク経路を使用してパスを確立するための手段と、計算された明示的な最適ネットワーク経路の障害時に、計算された明示的な最適ネットワーク経路より劣る代替経路に切り換えて正常に機能するようにするための手段と、コミッションされたパスを計算された明示的な最適ネットワーク経路に再ネゴシエートしようと試みるための手段と、明示的な最適ネットワーク経路が再び利用可能であると判定するための手段と、その経路が再び利用可能であると判定されたとき、コミッションされたパスを計算された明示的な最適ネットワーク経路に切り換えるための手段とを含む、システム。
請求項11
第１の通信エレメントがルータであり、第２の通信エレメントもまたルータである、請求項１０に記載の、パスの確立を要求するＩＰネットワークにおけるルーティングの最適性を向上させるシステム。
請求項12
明示的な最適ネットワーク経路を自動的に計算することが、複数のパス計算エレメントによって行われ、複数のパス計算エレメントのそれぞれが複数のパス計算エレメントの他の１つまたは複数と通信し、複数のパス計算エレメントのそれぞれが第１のネットワーククラウドおよび第２のネットワーククラウドのうちの少なくとも１つの中に複数の通信エレメントのすべてのビューを有する、請求項１０に記載の、パスの確立を要求するＩＰネットワークにおけるルーティングの最適性を向上させるシステム。
請求項13
明示的な最適ネットワーク経路を自動的に計算することが、第１の通信エレメントから受信された要求に応じて行われる、請求項１０に記載の、パスの確立を要求するＩＰネットワークにおけるルーティングの最適性を向上させるシステム。
請求項14
パス計算エレメントがルータの中にある、請求項１０に記載の、パスの確立を要求するＩＰネットワークにおけるルーティングの最適性を向上させるシステム。
請求項15
パス計算エレメントがルータの中にない、請求項１０に記載の、パスの確立を要求するＩＰネットワークにおけるルーティングの最適性を向上させるシステム。
請求項16
コミッションされたパスを計算された明示的な最適ネットワーク経路に再ネゴシエートしようと試みることが、この試みが成功するまで継続して行われる、請求項１０に記載の、パスの確立を要求するＩＰネットワークにおけるルーティングの最適性を向上させるシステム。
請求項17
パス計算エレメントが、第１のネットワーククラウドおよび第２のネットワーククラウドの１つまたは複数のエッジノードの中にある、請求項１０に記載の、パスの確立を要求するＩＰネットワークにおけるルーティングの最適性を向上させるシステム。
請求項18
明示的な最適ネットワーク経路が通過する１つまたは複数のさらなるネットワーククラウドをさらに備え、１つまたは複数のさらなるネットワーククラウドがそれぞれ複数の通信エレメントを含み、またそれぞれ境界を有し、各ネットワーククラウドの中の複数の通信エレメントのそれぞれはこの境界を越えて各それぞれのネットワーククラウド外の他のどの通信エレメント間の接続性をも見ることができない、請求項１０に記載の、パスの確立を要求するＩＰネットワークにおけるルーティングの最適性を向上させるシステム。
請求項19
パスがマルチセグメントの疑似回線であり、コミッションされたパスが単一パスに結合された複数の疑似回線セグメントを含む、請求項１０に記載の、パスの確立を要求するＩＰネットワークにおけるルーティングの最適性を向上させるシステム。
請求項20
疑似回線セグメントが、ＭＰＬＳを使用して確立される、請求項１９に記載の、パスの確立を要求するＩＰネットワークにおけるルーティングの最適性を向上させるシステム。